Dify 实战发布于 2026-08-30

dify workflow的确定性与Hermes agent skill的"确定性"对比

基于 Dify 1.16.x + Hermes Agent 环境实测撰写（2026-08）。门户自用机器人选型案例的延伸讨论——回应读者在原文章下的疑问。

📖 摘要：上一篇文章说「门户机器人用 Dify 答，因为展示场景要确定性」。有读者问：Hermes 通过 skill 约束，不是也可以做到确定性吗？这篇文章正面回答这个问题：确定性分三层——流程、行为、输出。skill 约束能锁住行为层和部分输出层，但锁不住流程层，因为流程决策权始终在 LLM 手里。用我们自己的四个实测案例证明：文本约束是概率性服从，结构约束才是确定性执行。

📌 这篇文章要解决的疑问：你们说展示场景要确定性，所以用 Dify——但 Hermes 有 skill 约束啊，约束写好不也是确定的吗？

结论

skill 约束能做到「部分确定性」，但做不到 Dify workflow 那种「结构性确定性」。 关键在分层：约束 LLM 的行为 ≠ 消除 LLM 的决策。前者是概率性服从，后者才是确定性执行。

判断标准没有变：这个场景要的是「确定性」还是「自主性」？ 但「确定性」这个词要拆开看，拆开之后，答案就清楚了。

场景：原文章下的那个疑问

上一篇写了我们门户两个自用机器人（「认识我们」「AI 机器人」）为什么用 Dify 回答，而不是把本机的 skill 复制到云端 Hermes。核心论点：公开展示面要的是确定性（回答稳定、可审计、可发布），这是 Dify workflow 的结构优势。

文章发出后，有读者问了一个很专业的问题：

Hermes 不是可以写 skill 约束吗？约束写好了，让它按流程走，不也是确定性的吗？

这个问题问到点子上了——如果「约束」就能换来确定性，那 Hermes 也能做到，选 Dify 的理由就不成立了。所以我们认真把它拆开验证了一遍。

痛点拆解：确定性不是一回事，是三层

「确定性」这个词，实际包含三个不同的层面：

层级	含义	举个例
流程确定性	下一步走哪个节点、走哪个分支	问题来了，先查知识库还是先问分类器
行为确定性	某个处理具体怎么做	检索结果为空时，走兜底文案还是报错
输出确定性	结果格式、结构、结论稳定	回答永远是「结论+依据+建议」三段式

三个层面，skill 约束能覆盖的程度完全不同。

实测证据：skill 约束在哪里失效（四个真实案例）

以下全部是我们自己环境里的实测记录（Dify 1.16.x + Hermes Agent）：

#	约束场景	实测现象	说明
1	MCP 工具 docstring 写「禁止引用其他工具名」	模型仍按 docstring 里的工具名调用已禁用工具，日志实证多耗一轮调用	文本指令概率性失效
2	SOUL.md 写「知识库问题必须直接调 dify_ask，禁止先浏览器搜索」	部分提问仍先去浏览器/搜索兜一圈	全局指令概率性不生效
3	RAG 改写节点 prompt 约束「保留用户关键语义」	「OSPF 典型配置举例，请带组网图」被改成「OSPF典型配置组网图」——「举例」被删，命中全丢	LLM 自由改写覆盖约束
4	信息链路 prompt 要求「从给定列表原样照抄标题」	模型输出「英伟达芯片/价格战」等套路新闻——输入里根本没有这些内容	「原样照抄」类约束直接失效

四个案例是不同层级的问题：docstring 失效是「模型没读工具说明」，SOUL.md 失效是「全局规则和当前任务冲突时规则让路」，改写丢词是「LLM 认为自己在帮忙优化」，照抄跑偏是「模型自由发挥压过指令」。但它们有一个共同点：全是文本约束，全在概率性地服从。

对照我们跑过的 36 次会话、3 种约束写法对比实验（无约束 / 精简铁律 / 结构化约束）：结构化约束能把「执行达标率」从 88% 提到 100%，但代价是 token 消耗涨 44%——约束是在「提高概率」，不是在「锁定结果」。同一个输入，约束生效时走 A 路径，某次不生效时可能走 B 路径——这就是概率性。

本质：约束 LLM vs 消除 LLM

Dify workflow 为什么能做到确定性？因为它根本不把流程决策交给 LLM：

	skill 约束（Hermes）	workflow（Dify）
机制	约束 LLM 的行为——模型概率性服从文本规则	消除 LLM 的流程决策——节点顺序/分支由平台强制执行
失败模式	静默漂移：绕过一条铁律，结果错但系统显示正常	不存在「不服从」——路径固定
可审计性	这次为什么没遵守 skill？无法稳定复现和解释	节点级执行记录，每步输入输出可查
维护成本	每条约束要实测验证，约束之间还可能冲突	画完即固定，改流程是改图

一句话：skill 是「告诉 LLM 应该怎么做」，workflow 是「直接规定怎么做」。前者靠说服，后者靠结构。

所以回到那个疑问：「Hermes 写 skill 约束不也是确定性吗？」——行为层可以接近，流程层做不到。 展示场景最要命的恰恰是流程层：同一个问题，这次先查知识库、下次先问分类器，答案结构就漂了，而你没法向访客解释「为什么昨天和今天不一样」。

那 Hermes 什么时候也能确定性？

有边界，但不是没有解。我们实际用的两条：

方法	原理	例子
判定下沉为确定性脚本	把「该走哪条路」从 LLM 手里拿走，写成 if-else 代码	检索结果判空、格式校验、兜底分支——全部 code 节点/脚本处理，LLM 只做最后文案
LLM 只做生成不做决策	信息链路用确定性节点直出内容，LLM 留在自由生成任务	资讯链路：code 节点提取标题+摘要直出，LLM 不接触原文

这两条的本质和 Dify workflow 是同一个原则：确定性靠「移除 LLM 决策」实现，不靠「约束 LLM 决策」实现。 我们能把它写在 Hermes 里，但每个点都要自己写代码、自己测——Dify 是把这套做成了平台能力，画图即有。

边界：不是「skill 没用」，是「skill 的用处不在锁定确定性」

说清楚，防止误读：

不是「skill 约束没用」。我们的 36 次实验证明结构化约束把达标率从 88% 提到 100%——约束在「提高自主执行的稳定下限」上非常有用，Hermes 内部交付天天靠它。
不是「Hermes 不能确定性」。判定下沉为脚本后，工具层和 Dify 的 code 节点一样确定。但这是「你主动把决策拿走」，不是「约束让 LLM 自己守住」。
不是「展示场景永远用 Dify」。如果门户机器人未来要自主操作（自动生成方案、调用内部系统），它就该进化成 Hermes 形态——选型是动态的，场景变了工具就变。

收尾

回到那个疑问：Hermes 用 skill 约束，不是也能做到确定性吗？

能，但只能到行为层；流程层的确定性，靠的是把决策权从 LLM 手里拿走——Dify 把这做成了平台能力，Hermes 要靠你自己写。

所以门户机器人还是用 Dify：不是「约束不够好」，是展示场景要的不是「更聪明的回答」，是「更确定的回答」——而确定性这件事，结构比说服可靠。

本文基于真实工程实践记录撰写（Dify 1.16.x + Hermes Agent 环境，门户机器人选型案例延伸讨论）。文中实验数据（36 次会话/3 写法对比、达标率 88%→100%、token +44%）均来自我们自己的实测记录，理论与推断部分已标注边界。AI 参与创作声明：本文由 AI 辅助写作，内容基于作者真实实测记录。

本系列 · Dify 实战